Size Change: +1.23 kB (0%)

Total Size: 1.25 MB

_{compressed-size-action}

I added some designs to the original issue some of which could be applicable here.

@tellthemachines Thanks for the review

move to

I'm not familiar with this feature personally, in my testing in both trunk and this branch, it works very weirdly if you're a mouse user. Or I should say, it doesn't work if you're a mouse user. It took me some time to figure out that it works using keyboard only and it seems to behave in the same way for me in both here and trunk. Maybe I'm missing something?

A slight issue I noticed in testing is that the in-between inserter tends to disappear after a block is moved

Yeah, I noticed this, there's a number of situations where these inserters don't seem to respond properly. I haven't been able to find the reasons for these yet. I'm considering only showing the inserters relative to the selected block to try to mitigate this but I'll try to figure out more.

It took me some time to figure out that it works using keyboard only and it seems to behave in the same way for me in both here and trunk. Maybe I'm missing something?

No, that's how it works. Ideally it should work with mouse too, but we never found a good way of doing that. As it is, it's the only way of moving blocks between nesting levels with keyboard only, so if we were to re-think it we'd have to keep that in mind.

Yesterday I was testing with Gutenberg.run, but I now checked out this branch and can confirm it's working properly. Not sure what happened there 😅

Yesterday I was testing with Gutenberg.run, but I now checked out this branch and can confirm it's working properly.

There was a bug in one of the selectors I changed, I didn't fix it specifically for this issue but maybe it was a side effect there too.

Side note on the "Move to" action, would it make sense to trigger one of the bottom left notifications when engaged explaining how it works? "Use the keyboard to position the block"

I've improved I think the positioning update of the in-between inserters, it's almost fluid. We can do better maybe but it's acceptable I think.

What do you all think is missing from this PR to consider it good enough for merge (v1)?

Thinking about the broader UX I believe this zoomed out view could represent an opportunity to fuse the template editor with the site editor. I shared a concept in #27847 (comment) which illustrates how we can use it to toggle the visibility of the full layout while working on a post. It is also conceivable that it could be the default site editing view as well.

However in both of those cases some of the features of this PR can be undesirable... I may still want to edit child blocks even while zoomed out to view the template, or I might want to concentrate on patterns while zoomed all the way in to my post. That's not to say that these features are not valuable, they are! But I think they might be more useful when you are zoomed further out (something that Matias alluded to in #39281 (comment)). If zoom is a feature of the site/template editor, then maybe these features come online at a certain zoom level, and perhaps this PR could represent phase one of that implementation?

So to bring all this back to something actionable... I think it might be good to try zooming out even further, and to ideate on the entry-point a bit.

I noticed it's still possible to select child blocks via List View. Should we adjust list view so that only root-level blocks are listed?

One other small thing: The gap beneath the document is disproportionately larger than the one above when zoomed out.

Noting that this is on my list to include in the next call for testing for the outreach program! Great work, folks. cc @ironprogrammer as test lead for 6.1 - this is good to have on your radar.

Nice, Anne, I would love to find out if the way this mode is invoked feels naturally discoverable, and what it instinctually gets used for! We have ideas and goals of course, but input can help inform that 👌

Update: Originally reversed the plus/minus suggestion 🤦🏼‍♂️. Corrected below.

This feature is smooth and feels very natural. A great addition for navigating template areas! 🎉

I would like to suggest using a different icon from chevronUpDown, since that icon is used elsewhere in the editor to move blocks. This can be confusing as it relates to two distinctly different user actions. For instance:

As an alternative that is consistent with many other interface tools, how about using a search ("magnifying glass") icon base, with a reset ("-") symbol* inside the circle to "zoom out" and activate this mode, and switch to a plus|create ("+") inside the circle when active to "zoom back in" (i.e. return to the normal editor state). This would still work in conjunction with reversing the colors for active/inactive state.

So the icon in the zoomed-out/active state would look something like:

Down the road, this may also set the stage for other zoom-like editor modes, such as "zooming in" another step for "Spotlight mode" to enter block isolation mode.

*There is currently no minus in this reference icon list.

I would agree that the chevrons aren't the best icon for it, but go a bit further and say: I'm not sure this button is the best way to invoke it. For this first version it was necessary to have a button, but I would love to see this mode integrated more seamlessly into a flow, rather than have a bespoke action on the toolbar. For example it might invoke by default as soon as you open the "pattern" tab in the inserter, or it could potentially be the default view for select mode. This is something to explore separately.

Yeah, the invocation tool is mostly for testing, but it doesn't make sense there, we should make it contextual to the actions that demand it.

but I would love to see this mode integrated more seamlessly into a flow, rather than have a bespoke action on the toolbar. For example it might invoke by default as soon as you open the "pattern" tab in the inserter, or it could potentially be the default view for select mode. This is something to explore separately.

When playing around with it - my instinct was that the zoomed out mode matched so naturally with thinking in patterns that I wanted them to work together that way...

• I go to add a pattern and see the zoomed out view
• I go to the zoomed out view and automatically see the pattern gallery

In terms of active states - I did also notice that there's no gap between the Zoomed out view toggle, and List view toggle.

Good note. Those buttons have zero gap and are 36x36, but should have 8px gap and be 32x32:

As we make such a change, should we also consider making the 36px tall Publish/Settings buttons 32px height?

With most buttons moving towards 40px height, the Publish button would be an exception and follow "toggle size" rules:

What do you think, @WordPress/gutenberg-design ?

I would love to unify the spacing in the top bar, it's all over the place right now.

Any reason not to make buttons 40px? Then they align with other controls and are easier to tap on touch devices.

Would need to see it, but since we use 32px for toggles elsewhere already, that size already feels well established.

Not all of the buttons are toggles though – ellipsis, undo, redo, mode switcher. Either way I'm not sure it's intuitive to unilaterally make all toggles 32px 🤔

I can't picture 40px being a responsible use of that space, though, so I do like the idea that we have just two sizes, 32 and 40 to work with, both being base8, rather than what we have now which includes 36 in some places.

I find it most important to focus on the usability aspect, and 32px touch targets are fairly small... iirc Material recommends a minimum of 44px. But yes, let's mock it all up and see!

A mobile experience is crucial, though, but if the large sizes don't fit it's always an option to have desktop specific sizes as well.

40px looks bananas for icon buttons 🙈

Figma

I don't find this offensive at all, but appreciate it's subjective 😄

👋 a heads up that git bisect points to this commit as having introduced #44481.

Yeah, the invocation tool is mostly for testing, but it doesn't make sense there, we should make it contextual to the actions that demand it.

Any update or follow-up to the flow and icon issue? I see only #44585 but I'm not sure there's any issue to keep track of the icon issue.

The icon is still there and it's terribly confusing: